1. Field of the Invention
This invention relates generally to the field of data processors. More particularly, the invention relates to a network security processor which provides for an intelligent and efficient allocation of processing and queuing resources.
2. Description of the Related Art
Communication networks and the number of users of such networks continue to increase. Moreover, on-line sales involving both business-to-business and business-to-consumer transactions over the Internet continues to proliferate. Additionally, the number of people that are telecommuting continues to grow. Both on-line sales and telecommuting are examples of the usage of communication networks that typically involves private and sensitive data that needs to be protected during transmission.
Accordingly, security protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL) 3.0, and Internet Protocol Security (IPSec) have been developed to establish secure sessions between remote systems. These security protocols allow remote systems to establish a secure session through message exchange and calculations, thereby allowing sensitive data being transmitted across the different communication networks to remain secure and untampered.
FIG. 1 illustrates an exemplary two phase client-server or peer-to-peer exchange to establish a secure session. In a first phase 105, the security negotiation phase, a network element 101 (the client or the first peer) and a network element 103 (the server or the second peer) exchange messages to negotiate security between the two network elements 101 and 103. The negotiation of security includes determining the algorithms (e.g., hashing algorithms, encryption algorithms, compression algorithms, . . . etc) to be employed by the two network elements 101 and 103. In a second phase 107, a key exchange phase, the network elements 101 and 103 exchange key information. The second phase 107 comprises the network elements 101 and 103 exchanging messages based on a selected public key algorithm and authenticating received messages. While the specific primitive tasks of these two phases vary for different security protocols, the primitive tasks for establishing a secure session can include the receiving of messages, transmitting of messages, generating of keys, generating of secrets, hashing of data, encrypting of data, decrypting of data, and calculating of random numbers.
Performing the tasks to establish a secure session is processor-intensive. If a general purpose processor acting as the host processor for a network element, performs these tasks, then the network element's system performance will suffer because processing resources will be consumed for the tasks. The results of poor system performance can impact a network and users in various ways depending on the function of the network element (e.g., routing, switching, serving, managing networked storage, . . . etc).
Security coprocessors have been developed to offload some of the tasks from the host processor. FIG. 2 illustrates an exemplary architecture for a security processor 200 which includes multiple execution cores 240. The network element 205 shown in FIG. 2 (e.g., a router, gateway, switch, . . . etc) transmits security operation requests to the security processor 200 via an I/O interface 210 (e.g., a PCI interface). The security requests are initially placed in an input queue 222. An execution core scheduler 230 reads the security requests from the input queue in sequence and farms out the security requests to each of the execution cores 240. For example, each execution core 240 may process a single security request at a time and the execution core scheduler may farm out individual security requests in a round-robin fashion. When an execution core 240 completes a security request, the results of the request are placed in an output queue 220 and provided to the network element 205 via the I/O interface. Various techniques for transmitting and queuing data between the network element and the host processor may be employed such as, for example, direct memory access (“DMA”) read/write operations.
The execution cores may be programmed with microcode to process different types of security operations such as SSL, IPSEC, or XML Digital Signature (“DSig”) operations. One example of an execution core 300, illustrated in FIG. 3, includes a microcode block 301, a microcontroller block 303, and an execution queue block 305. The microcontroller block 303 executes microcode stored within the microcode block 301. In one embodiment, the microcontroller block translates each security operation into one or more primitive security operations which are then distributed to execution queue block 305. Different microcode blocks may be loaded within the execution core 300 (e.g., via a driver when the system is powered up). For example, one type of microcode block may be specifically adapted for processing SSL operations whereas another type of microcode block may be adapted for processing IPSEC operations. By way of example, and not limitation, several different security operations are illustrated in the table in FIG. 4 along with their associated primitive security operations.
The execution queue block 305 is coupled to a set of primitive security operation blocks including, by way of example and not limitation, an Advanced Encryption Standard (AES) block 307, a Triple Data Encryption Standard (3DES) block 309, a modular exponentiation block 311, a hash block 313, a simple arithmetic and logic block 315, and an alleged RC4® block 319. Alternative implementations may include additional primitive security operation blocks or fewer primitive security operation blocks. A bus 321 couples the primitive security operation blocks 307, 309, 311, 313, and 319 and the register file block 317 together.
The input data for the operation (if any) is copied from the I/O interface 210 to the register file 317. The microcontroller block 303 retrieves the appropriate control information (if any) from the register file 317. The microcontroller block 303 places the necessary primitive security operations into the execution queue 305 for transfer to the security operation blocks 307, 309, 311, 313, 315, or 319. Once a primitive security operation block 307, 309, 311, 313, 315, or 319 has executed the primitive security operation, the results are copied to the register file 317. The results of the security operation (be it a macro or a primitive security operation), are then placed in the output queue 220 and transmitted to the network element 205 via the I/O interface 210 (e.g., by way of a DMA transfer to the appropriate location within the network element 205).
Current security processor configurations, such as those described above, are incapable of concurrently processing different types of data traffic and thereafter dynamically adapting to changes in data traffic. For example, current security processor configurations are incapable of concurrently processing both IPSEC and SSL data traffic. Moreover, no mechanisms currently exist for dynamically reallocating processing resources in response to relative changes in the processing requirements for each security protocol. Moreover, security coprocessors today are not capable of guaranteeing a specified level of service or bandwidth for certain types of secure data traffic.